Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-04

Text File | 1995-12-31 | 96KB | 2,630 lines

Path: ucivax!gateway
From: [e-mail] (Jonathan Pace)
Subject: How do I do this conversion.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 64
Date: 1 Apr 91 04:59:08 GMT

I have the following code working correctly on a spark station in Unix.  I want
to run it on my Mac IIcx in Think-C so I can get out of my profs office and do
the work for him at my house.  Can someone please tell me what's wrong.

  fp = fopen("DATA","r");
  fscanf(fp,"%d %d %d ",&(in->num_feeder),&(in->num_place),&(in->preamble));
  printf("# feeders = %d, # placements = %d, preamble = %d.\n",in->num_feeder,
          in->num_place,in->preamble);

/** this part is working.  the values printed out are correct **/

  in->x = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->y = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->feeder = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->rotation = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->board = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->id = (int *) malloc(sizeof(int)*(in->num_place+1));
  in->speed = (double *) malloc(sizeof(double)*(in->num_feeder+1));
  bin->x = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->y = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->feeder = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->rotation = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->board = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->id = (int *) malloc(sizeof(int)*(in->num_place+1));
  bin->speed = (double *) malloc(sizeof(double)*(in->num_feeder+1));
  bin->rotate = (double *) malloc(sizeof(double)*(in->num_place+1));

  for (node=0;node<in->num_place;node++) {
    fscanf(fp,"%d %d %d %d %d %d ",&(in->id[node]),&(in->board[node]),
       &(in->feeder[node]),&(in->x[node]),&(in->y[node]),
       &(in->rotation[node]));
    printf("node # = %d, id # = %d, board # = %d, feeder # = %d, x = %d, y = %d, rotation = %d.\n",
            node,in->id[node],in->board[node],in->feeder[node],
            in->x[node],in->y[node],in->rotation[node]);
  }
/**  this is where the problem is.  the values printed here are wrong, and my
Mac hangs up with the message "bomb" in the debugger  **/

the data file looks like this

142 17 2
0 1 0 -32768 3429 0
1 1 0 -5638 5638 0
2 1 92 -12616 12044 270
3 1 95 -11811 11760 180
4 1 7 -11485 10711 270
5 1 7 -12031 10685 270
6 1 90 -12661 11201 180
7 1 2 -12031 9850 90
8 1 7 -12819 10558 270
9 1 24 -11963 9042 180
10 1 14 -12407 8813 180
11 1 7 -12730 9837 90
12 1 2 -12489 9837 90
13 1 7 -10538 6146 180
14 1 13 -10276 5481 90
15 1 23 -10518 5481 90
16 1 103 -10462 5181 180
I just started programming C on the Mac, and I don't have that much under Unix.
Can someone please tell me what seems to be wrong.

Thanks,

Jon Pace










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: How do I do this conversion.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 1 Apr 91 12:20:23 GMT

>the data file looks like this
>
>142 17 2
>0 1 0 -32768 3429 0
>...

Well, I could be mistaken, but... While -32768 is a valid 16-bit signed
integer (MININT in effect), if the THINK C I/O library reads its negative
integers by reading them as positive integers and then negating them, it'll
get this wrong.

Do I get a gold star or a wooden spoon?

        Nick.











Path: ucivax!gateway
From: [e-mail]
Subject: Problem With A TCL Dialog Class
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (Joseph A. Brownlee)
Lines: 49
Date: 1 Apr 91 16:28:00 GMT

I've been rolling my own "dialog boxes" as I needed them and I decided to try
to start working on a class that would generalize the dialogs so that I could
easily define a dialog-like window without creating a new class for every new
dialog.  So, I took a piece of working TCL code I had written to do a single,
hard-coded dialog and began to generalize it, but I haven't had much success
getting it to work.

The CDialog class is a sub-class of CWindow.  I create a CPane to hang the
dialog item objects on.  I have methods to add buttons, static text, scroll
bars, etc. to the dialog window.  All calls check for memory allocation/object
creation errors.  The dialog window is created OK, and I can use the controls
in it and they work as expected.   The CStaticText objects are plotted
correctly.  However, when the user clicks the OK or Cancel button, and the
Supervisor invokes the CDialog::Dispose() method, my Mac freezes when it hits
the Dispose() method call on the CPane object (or if I'm lucky, the debugger
catches an odd address error).

Using the debugger, what I find is that any method call in the Dispose() method
to the CPane created within the window will croak (for example, I tried calling
SetWantsClicks() instead of Dispose()), so it is not the Dispose method itself
that is failing.  If I press the "In" button, it crashes immediately -- I do
not make it into the method at all, and the source code display does not change.
However, when the Pane is created and when the controls in that Pane are active,
everything is fine.  When I enter the Dispose() method, the Pane is already
trashed and any call which references it will crash.  The handle of the Pane
object hasn't changed, and I even tried adding checks to be sure it wasn't moved
around in memory behind my back and it wasn't.  The data shown for the CPane
object in the Data window all looks to be correct and the debugger has no
trouble displaying it.  I should also mention that the application I am using
to test the class is a clone of the Pededstal application, and I am not doing
anything special between creating the dialog and its Supervisor (a document)
calling its Dispose() method upon receiving the OK or Cancel "click command".

I've stepped through this code more times than I care to count, and I can't see
the problem.  Either it's something really obvious that I've missed, or I have
a basic misunderstanding of the TCL classes I'm using (CWindow, CPane, CView,
CControl, et al).  What I'd like is any advice or suggestions from the list
before I (possibly) waste bandwidth posting the actual class source.

In case this matters, I'm using THINK C 4.02 on an 8 MB IIcx under System
6.0.3.

Thanks in advance for any help.  The subscribers to this list have been very
helpful to me in the past.

   -      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] (Ta-Chun Lin)
Subject: Close AppleTalk
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 1 Apr 91 18:19:28 GMT

Hi Everybody:
  Dose anyone know which Toolbox Routine Call can close AppleTalk? I used
"MMPClose"
and "ATPUnload" to close and unload AppleTalk, but AppleTalk did not be closed.
Any
suggestion will be appreciated. Thanks in advance.

Shiem-Min Chen










Path: ucivax!gateway
From: [e-mail]
Subject: Re: How do I do this conversion.
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 18
Date: 1 Apr 91 22:33:39 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0910529360> of Mon Apr  1 04:59:08 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 702
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ehorvath-339>
UA-Content-ID: <MAC-1.3.4A1-618034-ehorvath-339>
MTS-Message-ID: <ehorvath0912224470>

>...Can someone please tell me what's wrong.
...
>  in->x = (int *) malloc(sizeof(int)*(in->num_place+1));
    [many similar statements]
>...my Mac hangs up with the message "bomb" in the debugger...

Put "#include <stdlib.h>" at the top of your file.  For reasons known only to
Finagle, in ANSI C 'sizeof' is replaced by an int constant, but malloc
requires a size_t.  In Think C 4.0, the latter is unsigned long.

I've replied to the list because this is one of those FAQs that bites
everybody who tries to use malloc with ThC.

A better bit of generic advice is to turn on the Require Prototypes option,
which will remind you to include stdlib.h when you forget.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: How do I do this conversion.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 2 Apr 91 09:32:11 GMT

>Yes, THINK C reads negative integers the way you describe.  But +32768 =
>-32768, and -(-32768) = -32768, so that shouldn't make any difference,
right?
>(or does it trap overflow?)

-32768 is a valid 16-bit integer. +32768 isn't. I don't know how the
library will deal with overflows (or what will happen if it doesn't,
regarding sign extension and so on).

        Nick.











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Problem With A TCL Dialog Class
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 2 Apr 91 09:33:42 GMT

The wonderful world of THINK C garbage collection. I can't help you in your
specific problem, but I had lots of hassles of a similar nature. You have
to be careful with Dispose() methods - it's all too easy to end up calling
a method in an object which has already been disposed (e.g. by an inherited
Dispose() method). I seem to remember that objects in the visual heirarchy
close themselves down in such a way that update events can appear as a
result of Dispose() calls, for example. Tracing calls to disposed objects
(and hence into hyperspace) is tricky - it's better to try and understand
exactly what gets disposed of in what order.

It's a hassle. This may help you in thinking through your problem, I don't
know.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: Problem with ListMgr
Message-ID: <910402918*[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 2 Apr 91 18:33:37 GMT

Hi,

I have been working on a class which displayes lists using the ToolBox ListMgr.
I have everything working very well, but with one exception.

When I try to create a list with a vertical scroll bar and a resize box (like
the lists that appear in the ResEdit pickers), the ListMgr does not leave room
for me to draw the resize box (the scroll bar runs the entire height of the
list).  I feel that I have specified the parameters to the LCreate call
correctly.  I've been over and over the section in InsideMac and searched
through the Tech Notes looking for clues.  Can anyone help?  Is there some
bit of Mac magic that I need to know?

Thanks in advance,

-Mark
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Ken Konecki)
Subject: FPU bomb with LC
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 16
Date: 2 Apr 91 20:33:07 GMT

My brother-in-law is trying to do some basic C programming (i.e.
no toolbox calls, just the ANSI library) on his LC and it keeps
bombing when he tries to do floating point arithmetic. I don't
have the exact text from the bomb dialog, but the summary is
that the code is expecting an FPU, but of course there isn't one
in the LC. The obvious answer is that the options were set to
generate 68881 calls, but that option was not set.

Any less obvious answers?

Thanks,
    -Ken K
--
Ken Konecki
"You call some place paradise, kiss it goodbye."
e-mail:[e-mail]    -or-    ...!uunet!tellab5!kenk










Path: ucivax!gateway
From: [e-mail]
Subject: VDSettings struct in Video.h - where is it documented?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 2 Apr 91 22:24:03 GMT



I can't find any mention of the VDSettings type anywhere but in Video.h where
it's defined.  I'd like to be able to use it to control the settings within
(csBrightVal, for example), but I can't even figure out which routine to send
it to.  Do I send it to PBControl, and if so, what would the csCode be?  Do I
use the slot manager, and if so, how?  I have already read 'Designing Cards
and Drivers', and 'Guide to the Macintosh Family Hardware' and of course IM.

_Any_ help would be much appreciated.

Thanks in advance,

Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail]                                  Compu$erve: 73567,1651
_____________________________________________________________________________
"The whole world is about three drinks behind."
        - Humphrey Bogart










Path: ucivax!gateway
From: [e-mail] (Cameron Christopher Long)
Subject: Random compile bugs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 3 Apr 91 18:21:12 GMT

Hey all...

Here's an interesting situation that I hope you can help me resolve:

We have a fairly good sized application going, and when we compile, we
occasionally get bad code. I have verified that none of the segments is
over 30K, but apparently some of the segments aren't being loaded during
execution, since we are getting bus errors and the like which indicate
that the code being called isn't there...

When compiling, we have about a 30% chance of getting good code, and the
other 70% of the time, certain functions don't work, or the program will
just crash in the middle of execution.

I realize that this is a rather vague description of our problem, but I
am hoping that someone will say "AH... I know what they are doing wrong!"

If you have any suggestions, comments, or see the obvious problem, please
send mail to:

[e-mail]


Thanks for your time,
Cameron Long

PS. THINK C v4.0.4










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ADMIN: About this list...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 76
Date: 4 Apr 91 02:40:32 GMT
Phone: [phone]

[Monthly posting]

        About... The Think C electronic mailing list
        --------------------------------------------

This list has been created to discuss topics of interest among users of
Symantec's Think C compiler for the Macintosh personal computer.  These
topics include:

    o programming tips and examples

    o discussion of compiler bugs and/or misfeatures and workarounds

    o questions related to programming the Macintosh with Think C and/or
      object-oriented programming

One request: if someone submits a question on something that seems simple to
you, please remember that it will seem simple to many of the other 300+
subscribers to the list.  Please reply to the sender directly unless you
feel it is warranted to broadcast the reply.  The person who submitted the
question is urged to followup at some time in the future with a summary of
responses, so others who might be interested can see what the solution was.
This simple rule will prevent much of the chaff that is present on many
mailing lists and newsgroups.

Archives of past discussions on the list are stored in the Think C Archive
(see below for access information) in the directory /mac/think-c/archives.

Requests for addition/deletion/address/questions changes should be sent to:

    [e-mail]

Submissions to the list should be sent to:

    [e-mail]

            About... The Think C Archive
            ----------------------------

An archive of submitted source code and other packages related to Think C is
available from ics.uci.edu via two transfer methods:

    o anonymous ftp to ics.uci.edu (128.195.1.1)

    o automated e-mail archive server on ics.uci.edu

The archive is stored in /mac/think-c for ftp.  To use the archive server,
send mail to:

    [e-mail]

Extensive help is available for this server by using a subject consisting of
the word "help."  For there, you should be able to determine how to navigate
the archive.

Submissions to the archive may be accomplished in one of two ways:

    o use anonymous ftp to drop the submission in /incoming on
      ics.uci.edu and send a note to think-c-request summarizing the
      submission.

    o use electronic mail to send the submission to think-c-request.

After the submission has been moved to the proper directory in the archive,
a notice will be sent to the list describing the new addition(s) to the
archive.  These notices will always have subject headers of the form
'ARCHIVE: xxx', where xxx is a brief description of the new addition.

WARNING: Items stored in the archive is not guaranteed in any way to have
been tested for functionality or absence of virii.  Retrieve and use at your
own risk.

Mark Nagel <[e-mail]>
Department of Information and Computer Science
University of California
Irvine, CA  92717










Path: ucivax!orion.oac.uci.edu!nntpsrv
From: [e-mail] (Bill Dugan)
Subject: 4.0 substitute for Stdio_Macinit(TRUE) ?
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: University of California, Irvine
Lines: 10
Date: 8 Apr 91 07:11:09 GMT
Distribution: usa

I just loaded an ancient project I made under Think C 3.0, and apparently the
standard library has changed for 4.0; one call won't link:

Stdio_MacInit(TRUE);  /* Prevent stdio from making the macintosh init calls */

I'm getting an odd-address error when I try running with this commented out,
so I'd assume it is calling some init call twice.  Can anyone help point me
to whatever call is being substituted?  Or am I missing a .h file?

bill










Path: ucivax!gateway
From: [e-mail] (Ace Stewart)
Subject: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 8 Apr 91 14:35:43 GMT


unsubscribe










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  4.0 substitute for Stdio_Macinit(TRUE) ?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 8 Apr 91 20:34:29 GMT

The THINK C 4.0 libraries are now sensitive to whether the Toolbox has
been initialized, so if you perform your own init calls, the console
package will not. Likewise, if you call a console routine such as scanf
or printf before initializing the toolbox, then the console package
will make the calls for you, so you should not call the inits.











Newsgroups: fa.think-c
Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: help with bison from the think-c archive
Message-ID: <[e-mail]>
Sender: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Distribution: na
Date: Wed, 10 Apr 1991 08:40:07 GMT
Lines: 18

I'm trying to use Bison as ported to the Mac and Think-C by rsfinn at
athena.mit.edu.  The problem is that the yacc.tab.c file produced by Bison
makes calls to "alloca" and "bcopy", both of which do not exist in
Think-C.  Anyone have any ideas on solving this cleanly?

[ Note: I can get around the problem by doing "#define yyoverflow", which does
something different instead of going to alloca and bcopy.  But I don't know
what the effect of doing this is, so I'm nervous about this "fix".  I think
it turns off the automatic extension of the stack when it overflows, a feature
I may want to keep. ]

Thanks in advance...

  - joe ([e-mail])
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: help with bison from the think-c archive
Message-ID: <[e-mail]>
In-Reply-To: Your message of "Wed, 10 Apr 91 08:40:07 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 10 Apr 91 13:34:53 GMT


bcopy() is memcpy() with the arguments in a different order.  memcpy()
is the ANSI standard function.

#define bcopy(source, dest, length) memcpy(dest, source, (size_t)length)
should do the trick.

alloca is a bit more difficult, but was extensively discussed in
comp.sys.mac.programmer a while ago. I could have sworn I saved some
of those articles, but I can't find them now. I don't see anything
likely at sumex, either.

Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142

        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.










Path: ucivax!nagel
From: [e-mail] (Mark Nagel)
Subject: Re: help with bison from the think-c archive
Nntp-Posting-Host: buckaroo.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: UC Irvine Department of ICS
Lines: 38
Date: 10 Apr 91 15:19:38 GMT
References: <[e-mail]>
Distribution: local

In <[e-mail]> [e-mail] writes:

>alloca is a bit more difficult, but was extensively discussed in
>comp.sys.mac.programmer a while ago. I could have sworn I saved some
>of those articles, but I can't find them now. I don't see anything
>likely at sumex, either.

Here's a copy of an article I saved from some time back.  It is an
assembly version of alloca for MPW C.  I'll leave it to others on
the list to decide whether it is OK for (and modify for) THINK C.
If we come up with a good alloca routine for THINK C, I'll add it to
the archives...

;;
;; Alloca() for Macintosh Programmer's Workshop C.
;; alloca(n) allocates n bytes of storage in the stack
;; frame of the caller.
;;
        CASE ON

alloca PROC EXPORT
        move.l  (sp)+,a0        ; pop return address
        move.l  (sp)+,d0        ; pop parameter = size in bytes
        add.l   #3,d0           ; round size up to long word
        and.l   #-4,d0          ; mask out lower two bits of size
        sub.l   d0,sp           ; allocate by moving stack pointer
        move.l  sp,d0           ; return pointer
        add.l   #-4,sp          ; new top of stack
        jmp     (a0)            ; return to caller
        ENDP
        END

Mark
--
Mark Nagel
UC Irvine Department of ICS   +----------------------------------------+
ARPA: [e-mail]       | If you can read this, you're not using |
UUCP: ucbvax!ucivax!nagel     | the Hubble Space Telescope.            |










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: alloca in THINK C
Message-ID: <[e-mail]>
In-Reply-To: Mark Nagel's message of 10 Apr 91 15:19:38 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 10 Apr 91 17:42:16 GMT

The MPW solution you posted should work; if you're interested, there's
a version of the "portable" GNU alloca() in the gawk package that
somebody ported to THINK C.  I think it's on info-mac, drop me a line
if you can't find it and want more info.

    -phil










Newsgroups: fa.think-c
Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: solution to Bison problem with alloca and bcopy...
Message-ID: <[e-mail]>
Sender: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Distribution: na
Date: Wed, 10 Apr 1991 18:20:48 GMT
Lines: 14

Thanks for the quick replies to my plea for Bison help.  It turns out that
"bcopy" can be defined using the standard memmove function (I used memmove
in case the blocks overlap, but I guess in this specific case they can't),
and "alloca" can be had by getting the source to Bison.  Bison contains
the portable GNU alloca function (see alloca.c), though you also need the
xmalloc/mallocate functions as well (see allocate.c).

Thanks again for the help everyone!

  - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: help with bison from the think-c archive
Message-ID: <[e-mail]>
In-Reply-To: Your message of Wed, 10 Apr 91 08:40:07 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 10 Apr 91 19:03:27 GMT

I haven't actually looked at the source code in quite some time, but
if I remember correctly, the THINK C source code to Bison itself
contains definitions for both alloca and bcopy.  Try poking around in
there for a while (hint: use multi-file search).

As others have pointed out, "bcopy" is "bmemcpy" with the arguments
reordered.  Also, the posted version of "alloca" will probably work;
the version I remember being in Bison is a "portable" version which
should also work (but whose actual behavior differs from the usual
version).

-- Russell S. Finn
rsfinn@{lcs,athena,}.mit.edu











Path: ucivax!gateway
From: [e-mail] (Bob Rahe)
Subject: MPW->THINK-C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 11 Apr 91 01:14:11 GMT


  I've been toying around trying to convert MacKermit from MPW to ThC. I
have been reasonably successful in most areas, in fact found some syntax
errors that MPW lets by apparantly, and some other anomolies, but they
can be handled with ifdefs and such.  One thing has got me really going
tho.  It seems that MPWC knows when to convert strings from C to Pascal
type when calling the toolbox.  And does it "behind your back" as it were.
Seems almost magical at times, 'cause I'd swear he can tell which type
a variable is (maybe not, I don't have an example handy).  Does anyone have
any ideas as to how to go about converting this kind of nastiness, without
the obvious brute force approach of rewriting?  Also, can someone explain
exactly what the algorithm is that MPW-C uses to do this?

    Thanks,
     Bob Rahe <[e-mail]>










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: MPW->THINK-C
Message-ID: <[e-mail]>
In-Reply-To: Bob Rahe's message of 11 Apr 91 01:14:11 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 11 Apr 91 13:22:13 GMT

   It seems that MPWC knows when to convert strings from C to Pascal
   type when calling the toolbox.  And does it "behind your back" as
   it were.

MPW C does provide an alternate set of toolbox interfaces for most
(all?) toolbox routines that accept strings.  These routines can be
distinguished from the usual toolbox calls since they're entirely in
lowercase.  There isn't anything magical about how they work, MPW C's
glue just calls CtoPstr on a copy of the string before calling the
toolbox.

For example:

void setctitle(ControlHandle itemHandle, char *theTitle)
{
    Str255 p1;

    strcpy((char *)p1, theTitle);
    CtoPstr((char *)p1);
    SetCTitle(itemHandle, p1);
}

I suppose it wouldn't be too hard to write a function that copies the
string as it's converted.

    -phil










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: MPW->THINK-C
Message-ID: <[e-mail]>
In-Reply-To: Bob Rahe's message of 11 Apr 91 01:14:11 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 71
Date: 11 Apr 91 13:27:27 GMT

I'm not sure if I've posted this before, but here's a list of problems
you may encounter when porting code from MPW C to THINK C.  If you can
think of any notes to add to this list, please drop me a line.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

---------------- mpwc-to-thinkc.txt ----------------
Here's a list of typical things to look for when converting a MPW C
header/program.  These comments apply to THINK C v4.0x only.

(1) The size of the int data type differs between MPW C and THINK C.
MPW C's int is 32 bytes, whereas ours is 16.

(2) THINK C does not support the const storage class specifier.
You can use:
#define const

(3) pointers to functions
THINK C doesn't support using the pascal keyword in typedefs.  Also,
it doesn't support function pointer types that contain argument lists.
Just use ProcPtr instead.

(4) inline function definitions
THINK C only supports pascal inline functions.  These functions can be
rewritten either by using a pascal function, or by using the inline
assembler with dc.w.

(5) // comments
A good grep to get rid of these things is:
Replace: "//\(.*\)$"  With: "/*\1 */" (don't type the double quotes)

(6) extended type
THINK C's double type corresponds to the SANE extended type.  To make
a header which uses "extended" compatible with THINK C, include the
following statements at the top of the header:

#ifdef THINK_C
  #ifndef extended
    #define extended double
  #endif
#endif

(7) signed char type
THINK C supports char and unsigned char, but not signed char.
Variables declared as signed char for MPW C should be declared as char
for THINK C.

(8) pascal function return types
In THINK C, pascal functions may return only void, integers, or
pointers.

(9) THINK C enums are 16 bits
In enums, left shifts of more than 15 bits (1 << 15) will not work.
Use #define instead.

(10) comp
THINK C doesn't support the comp data type

(11) pascal function argument size
In THINK C, parameters to pascal functions must be no larger than 4
bytes.  Instead of passing large structs, pass pointers to these
structs.  (Also, instead of passing a Str255 or Str32, pass a
StringPtr.)

(12) foo[0]
THINK C will flag "fooType foo[0];" with an "illegal array bounds"
error.  Use "fooType foo[1];" instead.










Path: ucivax!gateway
From: [e-mail]
Subject: More Problems With Dialog Class
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (j.a.brownlee)
Lines: 26
Date: 11 Apr 91 13:53:28 GMT

I solved my problem with the Dispose method in my Dialog class.  I now have an
approach question.  As per one of the Tech Notes (#38?), I am using a real
window for my dialogs, since the "dialog" could potentially have many controls.
However, this leads to some problems with modality.

I'd like to be able to support "modal" dialogs (or perhaps semi-modal is more
accurate?).  By this, I mean that it would be OK for the user to switch
applications, but I want the current application to be "frozen" until the user
makes a selection.  To accomplish this, I would at least need to disable all of
the menus in the application and to prevent the user from activating another
of the application's windows.  Have I missed anything here?

Assuming the above to be correct, there is no general way in the TCL to disable
all of the menus that I can see.  To do it, you must know all of the menu IDs.
I suppose I could add such a method to CBartender.  However, I know of no way
to keep the user from selecting another window unless I try to grab all of the
events for myself and only act on clicks in my dialog window.  Would this be a
better approach to the problem?  If I take this approach, how much will this
cause problems for supporting modeless dialogs?

Any advice from all of you TCL gurus is greatly appreciated.  Thanks.

   -      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail]
Subject: MPW->THINK-C : string conversions
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 51
Date: 11 Apr 91 15:15:39 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet1010134230> of Thu Apr 11 01:14:11 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 2413
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ehorvath-356>
UA-Content-ID: <MAC-1.3.4A1-618034-ehorvath-356>
MTS-Message-ID: <ehorvath1011500470>

------------ Original Message -------------
  I've been toying around trying to convert MacKermit from MPW to ThC. I
have been reasonably successful in most areas, in fact found some syntax
errors that MPW lets by apparantly, and some other anomolies, but they
can be handled with ifdefs and such.  One thing has got me really going
tho.  It seems that MPWC knows when to convert strings from C to Pascal
type when calling the toolbox.  And does it "behind your back" as it were.
Seems almost magical at times, 'cause I'd swear he can tell which type
a variable is (maybe not, I don't have an example handy).  Does anyone have
any ideas as to how to go about converting this kind of nastiness, without
the obvious brute force approach of rewriting?  Also, can someone explain
exactly what the algorithm is that MPW-C uses to do this?

    Thanks,
     Bob Rahe <[e-mail]>
--------- End of Original Message ---------

Look carefully at the trapnames used: unlike pascal, C distinguishes names
based on case.  So, Apple provides TWO sets of traps in MPW C, one set with
implicit string conversions, one without.  BUT (isn't this fun?) Apple also
CHANGED THE RULES between MPW 2 and 3, so the vintage of your source affects
the interpretation:

In MPW 2.x, you could call (for example) either
        DrawString ("a string");
or
        DRAWSTRING ("\Pa string");
i.e. the normal, mixed-case trap name got you a free conversion from C to
pascal on the way into the toolbox, and (where necessary, like "GetVol") on
the way out.  The all-uppercase trap was the "real," unadorned, do me no
favors trap.  The mixed-case trap also converted int (which is the same as
long in MPW C) to short for you (this shouldn't be a problem in ThinkC, which
will demote longs when they're passed to traps expecting shorts).

In MPW 3.x, the rules changed: now you use
        DrawString ("\Pa string");
or
        drawstring ("a string");
i.e. now the all-lower name gets the free conversions, and the mixed-case name
is the unadorned trap.

To add to the confusion, whether you call SFGETFILE, sfgetfile, or SFGetFile,
the trap will NOT attempt convert the filename in the SFReply record.  This
leads to a lot of FUD (Fear, Uncertainty, and Doubt).  I, and most C
programmers I respect :-) avoid the funny traps altogether -- it makes for a
simpler mental model.

Hope that helps.

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: THINK C version of regcomp/regexp
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 15
Date: 11 Apr 91 17:16:34 GMT
Phone: [phone]

Date:    Wed, 10 Apr 91 21:31:00 EDT
From:    arch3![e-mail] (Donald S Klett [phone])
Subject: Re: THINK C version of regcomp/regexp

The regular expression set of C subroutines developed by Henry Spencer at the
University of Toronto has been ported to run under THINK C 4.02.  I would be
happy to e-mail copies of the source to anyone that makes the request.  The
ported code passes the "test" file included with the original source from
Toronto.

        Don Klett
        att!arch3!dsk
        [phone]

[saved as: /mac/think-c/code/regex.hqx; 52K]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: MPW->THINK-C
Message-ID: <[e-mail]>
In-Reply-To: Your message of "11 Apr 91 13:27:27 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 11 Apr 91 17:48:02 GMT


Another major headache in MPW->Think C conversion is low memory
globals.  MPW defines low memory globals as constant addresses, which
you have to cast to the appropriate pointer type in order to use them.
Think C, much more logically, defines low memory globals as data items
of the appropriate type at a fixed address.

It's a real pain to find all these short of examining every cast to
pointer type in a program.

Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142

        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.










Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: Curses
Message-ID: <910411961*[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 11 Apr 91 21:29:06 GMT

Hello,

Does anyone know of a PD curses library for Think-C (supports the console
library).  Failing that, is there a GNU one that I could port?

Thanks in advance,

-Mark










Path: ucivax!gateway
From: well![e-mail] (John Draper)
Subject: Some good and bad things about TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 69
Date: 15 Apr 91 02:53:52 GMT

    One of the greatest things that really influenced me into purchasing
Think C Ver 4.0 and the Class Library was the straight forward approach
to Macintosh application development.

    The manual was pretty well written and fairly easy to understand,
at least for an "Average level" programmer.   But,  there is a hidden
little "Gotcha!!" that has gotten little mention in any of the user
groups and Network discussion,   but would have influenced my decision
to use Think C,  had I known about it.    I'm sure that some casual
mention might have been made,   but I don't have the time to read
ALL net traffic.

    So now,  here is the Gotcha! that I discovered which should
be pointed out to those people thinking of seriously using TCL
to develop a product.

    The problem is the CPanorama class,  and it's inability to handle
large panoramas which span beyond a pixel range of 32,767 pixels in
either the vert of horizontal direction.    If your application will
NEVER go beyond that range,  then please ignore this note.    But if
you are developing a CAD program,   or any other program that displays
objects in a large panorama exceeding the 32,767 pixel range,  then
I strongly urge you to either consider using MacApp,  or another
Class library,   or to write a letter to Symantic to urge them to
re-write CPanorama class,  or better yet to have someone else re-write
CPanorama.    Perhaps the people at Lexington Software Design (Prepare
Newsletter) might want to implement a new version of CPanorama and
CScrollPane to deal with this serious problem.    I would be glad to
do this myself,   but I neither have the time,  nor the know how to
do a good job,  and now have to explain to an un-forgiving client,  and
take a large financial lose as a result of this trap.

    So,  I would like to hear from those folks at Symantic who have
made appearances here in the past,   and what they have to say about
this.    For instance,  why hasn't there been a mention in the manual
about this serious limitation??   Nor has there been any mention in
the so called well commented source code.    It took me weeks to
un-ravel the intricate TCL scrolling and display mechanism to determine
this limitation.    So I am posting this to tell others about this
serious problem in the hopes that others won't fall into this trap,  and
that first-time users of TCL should carefully examine for other flaws
and "Gotchas!".

    I am not on Internet,  so don't have access to the Think C Archive,
and would appreciate it if someone could Email me a list of what is
up there.   I am particularly interested in knowing if there is a fix
for the CPanorama's 32k pixel limit,   or an alternate mechanism
for dealing with this problem,  plus I have some code that might be
of interest to those implementing Modal Dialogs as Objects,  and
it uses the DITL format so ResEdit can be used.    It also allows
ResEdit to specify "user items" as custom TCL panes.    I was hoping
to have gotten this put together a lot sooner,   but fell into this
trap,  so it might be a while now before I can spare the time to
get it ready for Public domain use.    It took me a long time to
put this together and get it working in conjunction with the Mac
Dialog Mgr.   It was NOT a trivial task to accomplish,  as it took
lots of digging around in ROM code to figure out how to do it.

    I also just got AppMaker Ver 1.1 which generates TCL code,  and
want to know what other people think of this product.    I haven't had
a chance to use it yet,  but want to know if it was worth the money.

Thanx in advance...
John D.

[e-mail]













Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Some good and bad things about TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 15 Apr 91 12:12:51 GMT

>I would be glad to
>do this myself,   but I neither have the time,  nor the know how to
>do a good job,  and now have to explain to an un-forgiving client,  and
>take a large financial lose as a result of this trap.

The Macintosh is a 16-bit system. The 68000 is a 16-bit chip and the 68030
Macs have the same software environment. This is very common knowledge
(although there are enough queries about people wondering why printing out
an integer value of 100000 doesn't work). It's inconvenient, but it's no
particular weakness of the TCL. If you want to flame Symantec, fine, but if
you go around assuming you've got 32-bit ints everywhere you're going to
fall over again, and rather soon, I expect.

... an eye for an eye, a flame for a flame... :-)

        Nick.











Path: ucivax!gateway
From: [e-mail] (Rick Holzgrafe)
Subject: Re- Some good and bad thing
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 15 Apr 91 17:47:19 GMT

 Internet Mail          Re: Some good and bad things about TCL
John Draper <well![e-mail]> writes:
>    The problem is the CPanorama class,  and it's inability to handle
large panoramas which span beyond a pixel range of 32,767 pixels in
either the vert of horizontal direction.

QuickDraw itself uses signed 16-bit integers for pixel addressing. All
Macintosh developers have had to take this into account, except for those using
MacApp, which jumps through hoops to present a 32-bit graphic interface.

Note that QuickDraw is not the only part of the Toolbox which has this
limitation. Standard scroll bars, for example, have a maximum range of -32767
to 32,767.

-----------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014













Path: ucivax!gateway
From: [e-mail]
Subject: Re: Some good and bad things about TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (j.a.brownlee)
Lines: 22
Date: 15 Apr 91 22:16:57 GMT

> John Draper <well![e-mail]> writes:
>    The problem is the CPanorama class,  and it's inability to handle
> large panoramas which span beyond a pixel range of 32,767 pixels in
> either the vert of horizontal direction.

For most applications (as you yourself say) this is not a problem.  However,
your statement that it is not "documented" isn't really true.  First, QuickDraw
itself is limited to 64K pixels in each direction (see IM-I).

Second, I find the TCL to be _very_ clear about such limits.  There aren't many
(at least none I can recall) parameters to any of the methods that aren't
defined as either "long" or "short" -- not type "int".  This to me is an
explicit statement about the range of values allowed for such parameters.  I
don't know about others, but one of the first things I check out when using a
new C implementation is the size of the various data types.  Therefore, the
allowable ranges are known immediately upon checking the types of a given
method's arguments.

   -      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] (Larry Watanabe)
Subject: Re: Some good and bad things about TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 16 Apr 91 02:49:43 GMT


I think I have to come to defense of the person who is having
problems with the 16-bit limit of CPanorama. First, the limits
of Quickdraw are independent of the limits of CPanorama. It is
reasonable to have 16-bit limits on Quickdraw, as that is likely
all will need to draw to the screen (barring ultra-large monitors!).

However, it is perfectly reasonable to expect to be able to draw
very large documents that have a virtual extent much larger than
32,767 pixels in either direction. I think a thesis might qualify.

It wouldn't have been that hard to represent the position and
bounds using 32-bit integers. The limits of the scrollbars
aren't relevant, as you can always map more than 1 pixel to
a particular scrollbar pixel. In fact, the think c library
already supports this to some extent.

Although the Think Class library is clear about such limits,
I don't think that qualifies as an excuse for not supporting
larger Panoramas. I'm not blaming the implementers of the Think
Class library, as it is hard to determine these requirements
in advance. But how about a larger panorama class, and larger
textedit class, in the next release?

-Larry Watanabe [e-mail]










Path: ucivax!gateway
From: autodesk!henry![e-mail] (Gary Lang)
Subject: Some good and bad things about TCL
Message-ID: <9104160717.AA02160@henry>
In-Reply-To: [e-mail]'s message of 15 Apr 91 22:16:57 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 16 Apr 91 08:12:42 GMT

Also BTW, contrary to FBI reports, John is not the CEO of Autodesk.
Whether this is good or bad is hard to say ;-)

-g











Path: ucivax!gateway
From: autodesk!henry![e-mail] (Gary Lang)
Subject: Some good and bad things about TCL
Message-ID: <9104160716.AA02155@henry>
In-Reply-To: [e-mail]'s message of 15 Apr 91 22:16:57 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 16 Apr 91 08:13:32 GMT

BTW Draper is just sore because his protege wrote TCL and made good
with it, when the whole idea was his in the first place. Not knowing
the whole story except from various product managers from
Symantec/Think, it sounds to me like if Dow hadn't gotten the go ahead
from them to di it, the Crunch Shell may or may not have produced
anything as useful. What say you cap'n?

-g











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Some good and bad things about TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 45
Date: 16 Apr 91 10:18:42 GMT

>I couldn't disagree more with the intent of the above. The mac's 16 bit
>past should be long burried by now. Even MPW uses 32bit ints.

I agree that this *should* be the case - I was just saying that it isn't. I
don't know offhand what the performance penalty is on a 68000 if you do
everything in longs, but I would probably settle for that in exchange for a
unified 32-bit environment.

The only argument against this (and not a very good one) is that most of
the Toolbox believes in 16-bit ints. I would have nothing against spec'ing
them as taking shorts, however.

>When I first
>started program with ThinkC -- I would constantly get bit by the
assumption
>that I could use 'int' and expect rational behaviour (i.e. the 32 bit
behaviour
>that I was used to).

I've been using 32-bit machines for years (since the VAX in 1978), but
approached the Mac knowing that int = 16 bits (the Mac is only a personal
home computer, after all). Occasionally I'll trip over it (when some
constant #defined as a complex arithmetic expression works out at 34688
bytes, for example) but usually it's no problem.

Now, if you view the Mac as a workstation machine for CAD applications and
so on, yes, 16 bits for integers is pretty silly.

>I finally overcame this problem by the resolution to 'never mutter the
"int"
>word again'. Nowadays, everything is either a short or a long -- and if I
should
>call printf -- I generally cast all of the arguments to longs and use %ld.

Yup - I will probably end up doing this as well (and aliasing `int' to
something illegal).

>True -- this is not as efficient as it might be, but my debugging time is
more
>valuable then a few extra cycles of execution time.

Couldn't agree more.

        Nick.











Path: ucivax!gateway
From: [e-mail] (chapman alan)
Subject: How to do this window?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 17 Apr 91 05:43:09 GMT

I have recently been asked to assist on a research project to test the
benefits of a couple of different menu structures for an editor environment.
I have programming in C for quite a while but I have only dabbled in the Mac
environment (programming wise) a bit since I purchased Think C 4.0 about six
months ago.  I wonder what would be the best approach to the following problem:

I need to have a couple of windows on the screen (no menubar), upon the user
clicking the mouse, a further window opens up.  This window will have some
boxes containing some text linked by lines (indicating structure).  The mouse
pointer should then be moved into this window and the user allowed to move it
anywhere from there.  As the mouse is moved over the boxes in the window they
should highlight and dehighlight as the mouse is moved out of the box.  When
the user clicks in one of the boxes the scene ends and the number of the
selection is returned.  There are several other cosmetic things which should be
simple enough.  There is also an alternative menu style which we will be
testing also.  It involves a very similar approach but with indented lines of
text to indicate structure rather than lines and boxes.

Bear in mind that this is testing only for reseach purposes, so please no
flames about not using the standard mac interface guidelines.  The final
editor will most likely not even be on the Mac.

I would like as many ideas and recommendations as possible (general or
specific).  I would like to consider using the Think C Class libraries and
object oriented programming approach.  Is this advisable?

We have several books on order (Inside Macintosh Volumes and several other
books I have seen recommended on the network).

Thanks in Advance,
-----------------------------------------------------------------------------
Alan Chapman, Tutor, School of Info. Tech.| email : [e-mail]
UCSQ, Toowoomba QLD 4350, Australia.      | "PC's and me just don't agree!"
-----------------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail]
Subject: TCL history
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 60
Date: 17 Apr 91 09:57:22 GMT

In a recent message, Gary Lang wrote:

> BTW Draper is just sore because his protege wrote TCL and made good
> with it, when the whole idea was his in the first place. Not knowing
> the whole story except from various product managers from
> Symantec/Think, it sounds to me like if Dow hadn't gotten the go ahead
> from them to di it, the Crunch Shell may or may not have produced
> anything as useful. What say you cap'n?

As the author of the TCL, let me set the record straight.

First, I am not a protege of Draper. I am not a protege of anyone, with
the possible exception of my parents.

Scond, the TCL was _not_ Draper's idea. Draper had a concept for something
he called the "Crunched Shell." This was something like a glorified version
of TranSkel, a generic application framework. It was not object-oriented.
His idea was to have a group of programmers work on this project. He posted
messages on various BBS's asking for participants. Several people responded,
but I was the only one who actually did some work and shared the code
with Draper. Draper had some generic event loop and window management code
that we used as a starting point. For a while, we each added stuff and
exchanged the code.

At some point, Draper took an Apple Developer University course on OOP and
MacApp. He recommended that I read Kurt Schmucker's book "Object-Orient
Programming for the Macintosh." After reading this book, I started to write
my own generic framework, using OOP techniques. I was using THINK C 2.0 at
the time, which didn't even have a hint of OOP. I developed my own way
of message dispatching, using the preprocessor, function pointers, and a
little in-line assembly. I wrote all the code, but for a while, I shared
it with Draper.

During this time, Draper introduced me to Jorg Brown, who went on to
work at Symantec. At some point, I stopped giving all my code to Draper.
He kept annoying me with programming questions at all hours of the night.
The worst was when a police officer knocked on my door at midnight. The
officer told me that it was urgent to call Draper. Turns out that Draper
had a programming question, and was frustrated that he couldn't get thru
to me because my phone was busy for a couple hours (I was using my modem).
I later found out that he also got a phone operator to try and break in
on my line, claiming it was a medical emergency.

After the Boston MacWorld Expo in 1988, I got a call from Jorg regarding
my pseudo-OOP class library. Draper had shown a version of my code to
someone at Symantec, and Symantec was interested in including a class library
with their upcoming THINK C 4.0 package. Jorg knew that I, not Draper, had
written the code.

Eventually, I worked out a contract with Symantec to develop the TCL. I
had to rewrite everything to use the OOP syntax supported by the new
compiler. As with any rewrite, I made a lot of design changes, learning
from by past mistakes.

Anyway, the point of this whole story is that Draper had very little to do
with the TCL. At most, he can be credited with recommending that I read
Kurt Schmucker's book, introducing me to Jorg Brown, and showing some of
my code to Symantec.

-- Greg Dow










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: CommToolBox/TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 47
Date: 17 Apr 91 17:17:25 GMT

               CommToolBox/TCL
Hello all,

I'm working on a CommToolBox application using the Think Class Library, and
I've hit upon a major stumbling block.  I'll explain my problem, and hopefully
someone out there has some ideas or has tried to do something similar in the
past.

Problem:
   Part A:   When using an CTB Connection and/or terminal, the application must
call a few routines to make sure that the CTB gets events.  Some are pretty
easy to handle with TCL--I simply created a subclass of CChore to handle the
CMIdle and TMIdle calls.  But a couple are not so simple.  Most specifically
CMEvent, TMEvent, and FTEvent.  These calls allow the various CTB routines to
handle events meant for them.  To quote fromt he documentation for CMEvent:
   "When your application receives an event, it should check if the refcon of
the window is a tool's ConnHandle.  Such an event occurs, for example, when the
user clicks a button in a dialog box displayed by the connection tool.  If it
does belong to a connection tool's window, your application should call
CMEvent."
  The TCL documentation states recommends against modifying the TCL source, but
states "If you need to keep track of events as the Event Manager gets them,
it's probably easier to modify the CSwitchboard class to do this than to create
a subclass."  It sounds like this is what I want to do.  Any comments?

   Part B:  It appears that the TCL stores in a window's refCon field a pointer
to the CWindow object.  This is gonna make things a bit more difficult.  I'll
have to grab the refCon of the window, and then try to figure out if the refCon
is a CWindow *, a ConnHandle, a TermHandle, or an FTHandle.  I suppose I can
create a CList which contains a list of the CTB handles I create, and each time
through the event loop I could check to see if the refCon of the FrontWindow is
one of the handles in the list, but this seems rather slow and clumsy.  I don't
like the idea of doing that much processing every time through the event loop.
Or am I being paranoid?  Does anybody have any better ideas for a way to handle
this?

To recap my questions:  Should I go ahead and just modify CSwitchboard to
handle the CMEvent, TMEvent and FTEvent routines?  How should I determine
whether to call the CMEvent, TMEvent, or FTEvent? Does anybody have some sample
source code for the CommToolbox?

Thanks-

Tom
[e-mail]












Path: ucivax!gateway
From: autodesk!henry![e-mail] (Gary Lang)
Subject: TCL history
Message-ID: <9104171711.AA02974@henry>
In-Reply-To: [e-mail]'s message of 17 Apr 91 09:57:22 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 17 Apr 91 17:17:59 GMT

Thanks Greg for basically explaining what I was trying to say. That is
if you hadn't done it, it wouldn't have happenned... Sorry if the word
protege offended you; it wasn't necessarily an attempt at accurately
characterizing you at all.

However, the fact that John started the idea and that you were one
of those that responded but was "the only one that did some work"
means that it was his idea and that you started work on it as
a response to his missives. Just because he ended up being in the
way at some point doesn't erase the fact that you weren't doing
this until Draper did his call to arms over the net. That makes you
a protege at some level. But please, I give full credit to you
for excellent work. But you yourself are admitting that he started the
ball rolling on the idea. Why deny him that? Noone said he wrote one
line of TCL, certainly I didn't.

"At most, he can be credited with recommending that I read
Kurt Schmucker's book, introducing me to Jorg Brown, and showing some of
my code to Symantec. "

I see. He gave you the idea, pointed you to literature that made your
project useful, and gave you a contact at the company that ultimately
published your work. Boy, he didn't have much to do with TCL did he?
Come on now, give him a break.

-g












Path: ucivax!gateway
From: well![e-mail] (John Draper)
Subject: Thanx for the help...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 35
Date: 17 Apr 91 22:25:21 GMT

I want to thank everyone for their responses.    They have been most
helpful after filtering out some of the flames.    I cannot know
if these responses were sent to me privatly,  or if they went out
to other people in the mailing list.    I am not familiar with the
mechanism of mailing lists,  so I'll summarize the responses for
those new folks who might ALSO be interested in the responses.

Larry writes.....

>I think I have to come to defense of the person who is having
>problems with the 16-bit limit of CPanorama. First, the limits
>of Quickdraw are independent of the limits of CPanorama.

>It wouldn't have been that hard to represent the position and
>bounds using 32-bit integers. The limits of the scrollbars
>aren't relevant, as you can always map more than 1 pixel to
>a particular scrollbar pixel. In fact, the think c library
>already supports this to some extent.

Thanx Larry,  I can use all the encouragement I can get right now.

Yikes!!   The "flame factor" was pretty high on this posting...
I was just posting something that would help out a first time
TCL user,   something that if I had known earlier,   it would
have changed my decision to use TCL for this project in the
first place.  I admit to being a "weenie" as far as programming
goes.   I only wish I had access to this mailing list when I
first started using TCL.    I had NO contact with other TCL users
until 8 months later,  nor did I expect to get this many responses.

Many thanx for the replies and information.   And a special thanx
to the person or persons managing this mailing list,   for he is
doing a valuable service to all of us TCL users.












Path: ucivax!gateway
From: autodesk!henry![e-mail] (Gary Lang)
Subject: TCL history
Message-ID: <9104172239.AA03257@henry>
In-Reply-To: [e-mail]'s message of 17 Apr 91 09:57:22 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 17 Apr 91 23:13:49 GMT

Allow me to publicly aplogize for publicly speculating on the
relationship between Greg Dow and John Crunch. I'm full of it, and
have no business polluting the airwaves with this nonsense. Sigh. I
wish I had better electronic social skills.

-g











Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Please repost reply to TCL history
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 18 Apr 91 13:45:02 GMT

My Mac crashed while reading the reply to Greg Dow's TCL history note.
Would the person who posted please send me a copy of that posting.
Thanks.

Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jerome Chan Yeow Heong - 57875)
Subject: Think C Class Libraries
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 19 Apr 91 20:57:57 GMT

I've recently acquired a copy of Think-C but after reading through
the manuals, I've only had a hazy idea of how to use them. Can someone suggest a book that would be helpful for beginners in OOP, specifically for think-C.

Thank you!!











Path: ucivax!gateway
From: [e-mail] (Ernie Oporto 867-5212)
Subject: Re: Think C Class Libraries
Message-ID: <[e-mail]>
In-Reply-To: jerome AT ee.fit.edu -- 19 Apr 91 20:57:57 GMT
Newsgroups: fa.think-c
Lines: 3
Date: 20 Apr 91 16:04:13 GMT

The Macintosh Programming Primer: Inside the ToolBox Using Think C (Vol I and I
I).  They are great help.  I and many others will suggest these to start with.
                                                        --Ernie










Path: ucivax!gateway
From: well![e-mail] (John Draper)
Subject: Some more useful information
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 55
Date: 21 Apr 91 00:05:15 GMT


    I found yet another "Gotcha!!" in TCL that people should
know about.

    Because of the high overhead of Pane management,  it is
often necessary to "re-use" panes when it becomes necessary to
deal with a lot of them.    In order to do this,  it is possible
(And highly recommended) that if you have large panoramas,  and
want to re-use panes that have scrolled off the main viewing
area.    Not only does lots of panes cause poor performance,
but it bogs down the Mac memory manager by having lots of
handles.    Then New becomes agonizingly slow.

    The panes that are NOT used (IE:  out of view) can be hidden
via the Hide method.   Then,  when it becomes necessary to view
them (IE: they are scrolled into view),   information can be loaded
into them for display.    The mechanism really increases the
performance,   but causes headaches when printing.

    For example,  if you call Show() while the "printing" flag is
set,   this messes up the GrafPort,  because Show() in CPane,
calls Refresh().    I suggested fox for this should be added to
CPane,  so if you have no quelms about changing CPane,  then
the proper code for CPane::Show() should be as follows,   and
fixes this problem.     This way,  if any code calls Show() while
printing flag is set,   this won't cause problems.

Old:

void    CPane::Show()
{
    if (!visible) {
        inherited::Show();
        Refresh();
    }
}

New:

void    CPane::Show()
{
    if (!visible) {
        inherited::Show();
        if (!printing)
            Refresh();
    }
}

    Naturally,  you can add this code to a SubClass of a CPane
and it should work OK.    Just dont ever call Refresh() during
printing,   and with this fix,  you can now call Show(),  which
is useful when you want to re-use panes while printing.

John D.











Path: ucivax!gateway
From: well![e-mail] (John Draper)
Subject: A Better fix
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 72
Date: 21 Apr 91 09:01:15 GMT


    I have a cleaner fix for the printing problem.   I discovered
a LIT of things that it now fixes.    Currently,  in TCL,  it is
not possible to pass a text handle to CStaticText while the
print Grafport is "thePort".    In my earlier posting,   I Only
mentioned that Hide() calls Refresh.    It turns out that TCL
calls Refresh in other instances while printing.   So,  instead
of changing Hide NOT to call refresh,   I think it might be better
to modify Refresh so it doesn't muck up and steal "thePort".

    The culprit is RefreshRect,  in that during printing,  it calls
SetPort(macPort) which does the dirty stuff.    So I have modified
RefreshRect().   It not only fixed ONE printing bug,  but fixed
ALL of them.    The fix is as follows.....  and is now a current
fixture in my copy of TCL,  and it shouldn't have any side effects,
or affect other operations.    The other fix I proposed is also valid,
but this one should catch ALL problems unless you override and
do your OWN RefreshRect.    It is also possible to disregard the
earlier change,  and add this one.

Old RefreshRect
==============

void    CPane::RefreshRect(
    Rect        *area)                    /* Area in Frame coordinates        */
{
    Rect        aperture;                /* Visible area of Pane                */

    if (ReallyVisible()) {

        < Code ommitted to abide by copyright regs >
        < Just replace it with YOUR copy           >

    }
}

New RefreshRect
===============

void    CPane::RefreshRect(
    Rect        *area)                    /* Area in Frame coordinates        */
{
    Rect        aperture;                /* Visible area of Pane                */

    if (ReallyVisible() && !printing) {

        < Code ommitted to abide by copyright regs >

    }
}


    Remember,  this ONLY affects printing,   and it is un-necessary
to call InvalRect anyway,   because the print code is going to
be calling DrawAll instead of the Updating mechanism.

    If you are sure that you will NEVER be calling CPane::Refresh
while "printing = TRUE",  these changes are necessary.   But please
note that TCL calls Refresh in a lot of un-expected places.    Best
way to catch them all,  is to put a breakpoint after the statement
below in CPrinter::PrintPageRange.

    macPrintPort = PrOpenDoc(macTPrint, NULL, NULL);

    Then,  you put a breakpoint at CPane::Refresh(),  and if you
actually have code that calls Refresh(),  or call other TCL code
that calls Refresh(),  you will break there.    If this happens,
then the changes above will be needed if you expect printing to
work correctly.

John D.











Xref: ucivax comp.sys.mac.programmer:22360 fa.think-c:400
Path: ucivax!orion.oac.uci.edu!nntpsrv
From: [e-mail] (Bill Dugan)
Subject: GetNextEvent beeps at me instead of returning keyDown
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Summary: This has got to be a really stupid problem
Newsgroups: comp.sys.mac.programmer,fa.think-c
Organization: University of California, Irvine
Lines: 21
Date: 21 Apr 91 09:24:56 GMT

I'm tearing my hair out over this one.  I'm writing a Think C application
that uses the stdio functions.  In my event loop, it returns a mouseDown
correctly, and I can drag windows, choose menu items, etc.  But when I
hit a key, it just beeps at me.  GetNextEvent doesn't even take the
"case keyDown"; it just keeps cycling over and over waiting for an event.
I'm calling GetNextEvent(everyEvent,&myEvent) the same way I do in every
other program I've ever written, but this code is a couple of years old
and converted from a Think C 3.0 project.  The code did work under 3.0.
(I've since deleted that project and started a new one just in case it was
a corrupted project file, but no dash, same problem.  I have the same bug,
incidentally, under both System 6.0.7 and 7.0b4.)

Is there some kind of call I might inadvertently have made that will mask
out the keyDown event?  Or perhaps GNE thinks that the stdio window is a
DA window and attempts to take care of the event itself instead of returning
it to me?

Puzzled,

bill
(thanks in advance!)










Path: ucivax!gateway
From: [e-mail] (Ernie Oporto 867-5212)
Subject: Re: GetNextEvent beeps at me instead of returning keyDown
Message-ID: <[e-mail]>
In-Reply-To: bdugan AT teri.bio.UCI.EDU -- 21 Apr 91 09:24:56 GMT
Newsgroups: fa.think-c
Lines: 4
Date: 21 Apr 91 17:04:28 GMT

Becareful with the use of that GetNextEvent.  According to Mac Programming Prim
er, you should be checking to see if WaitNextEvent is implemented on your machi
ne.
                                          --Ernie










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: GetNextEvent beeps at me instead of returning keyDown
Message-ID: <[e-mail]>
In-Reply-To: Bill Dugan's message of 21 Apr 91 09:24:56 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 22 Apr 91 03:33:03 GMT

   Is there some kind of call I might inadvertently have made that
   will mask out the keyDown event?  Or perhaps GNE thinks that the
   stdio window is a DA window and attempts to take care of the event
   itself instead of returning it to me?

Actually, the stdio window (called the "console" window in v4.0) is
implemented as a self-installing driver, which behaves like a DA.  If
this window is frontmost, and if you've done the standard mac
initializations, then you will get beeps for keydowns.  This is
because the console library only receives input if you haven't done
the standard mac inits.  The downside to this is that the console
window grabs the key events if it's frontmost even if it doesn't use
them.

The simplest way to fix this problem would be to make sure that the
console window isn't frontmost when your program receives input.

The less simple fix is to modify the driver event mask for the console
window, by looking up the console driver in the Unit Table.  If you're
interested in the trickier solution, I can post the code. (It's at
work, or I'd post it now.)

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Tom Johnson)
Subject: CommToolBox and TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 46
Date: 22 Apr 91 22:44:42 GMT

               CommToolBox and TCL
I have another question regarding the Think Class Library when used with
routine libraries such as the CommToolBox.  Various CTB tools (terminal
emulators, etc...) may intstall an additional menu to the menu bar.  When the
mouse is clicked in the menu bar, the application is supposed to then call
TMMenu, CMMenu, and FTMenu with the menuID and the itemNumber before doing
anything else.  TMMenu, CMMenu, and FTMenu return FALSE if they don't handle
the event.  If none of them handle the event, then it must be an application
menu.  Simple menu handling code might look like this:

--------

  theItem = HiWord(menuResult);
  theMenu = LoWord(menuResult);

  if (TMMenu(termHandle, theMenu, theItem))
       return;
  if (CMMenu(connHandle, theMenu, theItem))
       return;
  if (FTMenu(ftHandle, theMenu, theItem))
       return;

 /* it must be an application menu, so we will handle it here */
   switch (theMenu) {
        blah bah blah blah;
}

--------

I understand how you can build menus on the fly (ie a FONT menu) and have the
Bartender call DoCommand with a negative command number, but this only works
with Menus that have been registered with the Bartender via an AddMenu() call.
Since the CTB menus are never added to the MenuIndex table, FindCmdNumber (in
Bartender.c) can't locate the menu by it's ID, and always returns a cmdNull.
Not what I want, to say the least.

Is there any way I can get the MenuID so I can call AddMenu() myself?  Any
suggestions?
Greg Dow, are you listening? Can you help?

Thanks--

Tom













Path: ucivax!gateway
From: [e-mail]
Subject: TCL and Comm Toolbox menus
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 23 Apr 91 08:17:50 GMT

Having never used the Comm Toolbox, I don't know what mechanism it uses
to add its menus to the menu bar. However, you can always override how
the TCL responds to menu selections. The TCL calls MenuSelect in the
CDesktop::DispatchClick method. You can change the code (or create a
subclass of CDesktop) to call the CTB menu routines before it goes through
the TCL Bartender mechanism.

-- Greg










Path: ucivax!gateway
From: [e-mail] (Jerome Chan Yeow Heong - 57875)
Subject: Relayed Questions:
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 23 Apr 91 16:18:05 GMT

Hi again!

I've got a friend who has some questions to ask but he
does not have access to a machine so I`m posting this
for him.

----- /Start/ -----
    How does one copy a pixmap into a picture defination
so that it is not a series of quickdraw commands?
    Can you make a picture file from a pixmap and a picture
defination and how to do it with both ways, including writing
the color pallet to be used with the picture.
    How to read a PICT file and set the color table for that
Picture?
    How are pictures drawn so fast for games? Do they use
DrawPicture, or are they offscreen pixmaps which are stamped
onto the screen pixmap?
----- /End/ -----

I don't know what he's talking about, does anyone else know?

.Chaos










Path: ucivax!gateway
From: [e-mail] ("Spencer W. Thomas")
Subject: Relayed Questions:
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 23 Apr 91 17:45:57 GMT

I'll give a few of these a go.

 >     How does one copy a pixmap into a picture defination
 > so that it is not a series of quickdraw commands?
You make an offscreen pixmap and draw into it, then BeginPicture and
CopyBits from the offscreen pixmap.  It still ends up as a single
QuickDraw "CopyBits" command, but I think this is what he wants.

 >     How to read a PICT file and set the color table for that
 > Picture?
This was recently addressed here or comp.sys.mac.programming, I forget
which.  I don't remember the exact answer, but I note that a Pixmap in
a Picture generally has a color table associated with it.

 >     How are pictures drawn so fast for games? Do they use
 > DrawPicture, or are they offscreen pixmaps which are stamped
 > onto the screen pixmap?
Yes.

But seriously, ...  Most of the arcade-style games I've looked at the
internals of ((Beyond) Dark Castle, Continuum, e.g.) use the offscreen
bit/pixmaps approach.


=Spencer W. Thomas         EECS Dept, U of Michigan, Ann Arbor, MI 48109
[e-mail]        313-936-2616 (8-6 E[SD]T M-F)











Path: ucivax!gateway
From: [e-mail] (Bassel Soudan)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 23 Apr 91 18:09:20 GMT


Re : Problems or Bugs with CPane.

    It seems that everybody is talking about the problems with Refresh()
in the CPane definition. Well, here is another one.

    I am designing an interactive program that should allow you to move
Panes around ( I am using them to simulate fields [ala HyperCard]) The
problem is that if you move a CPane the Offset method calls Refresh() which
screws the thePort completely. In my situation, the origin of thePort is
somehow moved so that when you draw the screen after the moving is done,
the drawing will start somewhere close to the middle of the screen"!!!

    I debugged through the code (about three days of work) and finally
narrowed it down to this. I placed a SetOrigin statement before redrawing
the screen, and now everything is fine.

    I am not quite sure how to work this into the fixes that were
offered here? And can I get some input on what I am doing! Should I use
CPanes (decendents actually) to simulate HyperCard fields? If you have
something better please reply ASAP? One last question, How do I simulate
HyperCard buttons?? The CButton class seems to be directed towards buttons
that appear in control and dialog boxes.

    Sincerely yours,

    Bassel Soudan

    [e-mail]










Path: ucivax!gateway
From: bootsie![e-mail] ("Eric K. Olson")
Subject: Re: Relayed Questions
Message-ID: <[e-mail]>
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 29
Date: 23 Apr 91 22:16:16 GMT

In your message of Apr 23,  5:45pm, it is written:
>
> I'll give a few of these a go.
>
>  >     How to read a PICT file and set the color table for that
>  > Picture?
> This was recently addressed here or comp.sys.mac.programming, I forget
> which.  I don't remember the exact answer, but I note that a Pixmap in
> a Picture generally has a color table associated with it.
>

Executive Summary:  Read the Picture twice.  Set the QDProc for CopyBits
to your own routine (and all the others to a null routine, for speed)
the first time through.  Extract the PixMap Color Table from the source
(destination?) bitmap argument of your CopyBits routine (the BitMap can
actually be a PixMap-- you must do the cannonical test).  Save that,
reset the QDProcs, and read the Picture normally.

> =Spencer W. Thomas         EECS Dept, U of Michigan, Ann Arbor, MI 48109
> [e-mail]        313-936-2616 (8-6 E[SD]T M-F)
>
>


--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail] (Larry Watanabe)
Subject: 32-bit Panoramas
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 23 Apr 91 22:16:57 GMT


Last week someone posted some complaints about
the inability of CPanorama to handle panoramas with
visual extents larger than can be handled with 16-bit
coordinate system. I have lost his address and would
appreciate if someone would send it to me. I think
the e-mail address had the word "crunch" in it.

-Larry Watanabe [e-mail]










Path: ucivax!gateway
From: [e-mail] (Brent Schorsch)
Subject: Re: Relayed Questions:
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 24 Apr 91 18:42:42 GMT

Spencer W. Thomas ([e-mail]) says:
>
> >     How does one copy a pixmap into a picture defination
> > so that it is not a series of quickdraw commands?
>You make an offscreen pixmap and draw into it, then BeginPicture and
>CopyBits from the offscreen pixmap.  It still ends up as a single
>QuickDraw "CopyBits" command, but I think this is what he wants.
>

I have a question about this, the CopyBits is from the offscreen pixmap,
where is it to? Does it matter? does the clip region or visregion of the
destination have any significance? any other problems that mioght occur?
what if I want to do this but don't want anything visible, just copybits to
another offscreen bitmap?

-Thanks!
Brent


                              !  "He was strangely relieved about
Brent Schorsch                !   getting rid of his old fridge and
[e-mail]              !   looked forward to enjoying a new phase
                              !   of fridge ownership" -Douglas Adams










Path: ucivax!gateway
From: autodesk!mehitabel![e-mail] ("E. Richards")
Subject: Please remove Gary Lang from your list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 24 Apr 91 19:12:21 GMT


He has left the company.

    From MAILER-DAEMON@autodesk  Tue Apr 23 16:08:07 1991
    Return-Path: <MAILER-DAEMON@autodesk>
    Date: Tue, 23 Apr 91 16:11:20 PDT
    From: autodesk!MAILER-DAEMON (Mail Delivery Subsystem)
    Subject: Returned mail: Host unknown
    Message-Id: <[e-mail] >
    To: Postmaster@autodesk
    Status: R

       ----- Transcript of session follows -----
    bad system name: henry
    uux failed. code 68
    550 henry![e-mail]... Host unknown

      ----- Message header follows -----
    Return-Path: <[e-mail]>
    Received: from ics.uci.edu by autodesk.uucp  (4.1/SMI-3.2)
        id AA14360; Tue, 23 Apr 91 16:11:20 PDT
    Received: by fernwood.mpk.ca.us; id AA03374; Tue, 23 Apr 91 15:41:48 -0700
    Received: from ics.uci.edu by ics.uci.edu id aa27959; 23 Apr 91 15:19 PDT
    Received: from USENET by ics.uci.edu id aa27920; 23 Apr 91 15:18 PDT
    From: Larry Watanabe <[e-mail]>
    Subject: 32-bit Panoramas
    Message-Id: <[e-mail]>
    Newsgroups: fa.think-c
    Date: 23 Apr 91 22:16:57 GMT
    To: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: Protoclip 1.2
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 33
Date: 25 Apr 91 23:02:36 GMT
Phone: [phone]

    [Administrative note: Last time I posted an ARCHIVE notice, many ]
    [people asked me to send them the package.  As stated in the     ]
    [list description blurb, you can retrieve files via anonymous ftp]
    [or via mail using the archive-server address.  I will not send  ]
    [any individual anything unless there has been a failed effort at]
    [retrieving files the supported way.  -Mark                      ]

From: Alex Chaffee <[e-mail]>
Subject: Protoclip 1.2 (w/ source)
Date: Thu, 25 Apr 91 12:40:14 PDT

[Here's a submission for the archives.]

This FKEY takes any C source code in the clipboard and converts it into a
list of ANSI prototypes, ready for pasting. The prototyping code is based on
a Unix program called mkptypes by Eric R. Smith ([e-mail] or
@uwovax.bitnet). Since it's in the public domain, protoclip is freeware.

It works with Think C methods and some C++ constructs (not operator
overloads, for example).

Full Think C source is included - including a module for treating a Handle
like a FILE * (sort of).

 - Alex

--
Alex Chaffee
[e-mail]
Reed College, Portland OR 97202
____________________

[saved as: /mac/think-c/compiler/protoclip-12.hqx; 50K]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: 32 Bit QuickDraw header file for Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 151
Date: 26 Apr 91 21:57:43 GMT

This file may already be in the think-c archives, but I couldn't find
it when I looked around.  This is the official Symantec interface file
for using Apple's 32 Bit QuickDraw with Think C v4.0.  You will need
the 32 Bit QuickDraw INIT or a machine that has 32 Bit QuickDraw in
ROM (or, I guess, System 7) to use these calls.

This version fixes the bug that many other copies of this header had,
including the one that's in Dave Mark's "Macintosh C Programing
Primer", volume 2.  This bug involves the bit shifts in the GWordFlags
enum that are larger than 16 bits.

For those of you that are working with System 7, this file is
superseeded by QDOffscreen.h.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

---------------- QuickDraw32Bit.h ----------------
/************************************************************

 *  Copyright (c) 1989 Symantec Corporation.  All rights reserved.
 *
 *  These interfaces are based on material copyrighted
 *  by Apple Computer, Inc., 1985-1989.
 *

************************************************************/


#ifndef _QuickDraw32Bit_
#define _QuickDraw32Bit_

#ifndef _Color_
#include <Color.h>
#endif

/* New Constants for 32-Bit QuickDraw */

#define ditherCopy 64            /* Dither mode for Copybits */
#define RGBDirect 16            /* 16 & 32 bits/pixel pixelType value */


/* New error codes */

#define rgnOverflowErr -147        /* Region accumulation failed. Resulting region may be currupt */
#define pixmapTooDeepErr -148    /* Pixmap is not 1-bit/pixel for BitmapToRegion */
#define insufficientStackErr -149 /* QuickDraw could not complete the operation */
#define cDepthErr -157            /* invalid pixel depth passed to NewGWorld or UpdateGWorld */


/* Flag bits passed to or returned by Offscreen routines */

enum  {
    pixPurgeBit = 0,
    nowNewDeviceBit = 1,
    pixelsPurgeableBit = 6,
    pixelsLockedBit = 7,

    mapPixBit = 16,            /* set if color table mapping occurred */
    newDepthBit = 17,            /* set if pixels were scaled to a different depth */
    alignPixBit = 18,            /* set if pixels were realigned to screen alignment */
     newRowBytesBit = 19,        /* set if pixmap was reconfigured in a new rowBytes */
    reallocPixBit = 20,        /* set if offscreen buffer had to be reallocated */
    clipPixBit = 28,            /* set if pixels were or are to be clipped */
    stretchPixBit = 29,        /* set if pixels were or are to be stretched/shrinked */
    ditherPixBit = 30,
    gwFlagErrBit = 31
};

#define    pixPurge        (1L << pixPurgeBit)
#define    nowNewDevice    (1L << nowNewDeviceBit)
#define    pixelsPurgeable    (1L << pixelsPurgeableBit)
#define    pixelsLocked    (1L << pixelsLockedBit)
#define    mapPix            (1L << mapPixBit)
#define    newDepth        (1L << newDepthBit)
#define    alignPix        (1L << alignPixBit)
#define    newRowBytes        (1L << newRowBytesBit)
#define    reallocPix        (1L << reallocPixBit)
#define    clipPix            (1L << clipPixBit)
#define    stretchPix        (1L << stretchPixBit)
#define    ditherPix        (1L << ditherPixBit)
#define    gwFlagErr        (1L << gwFlagErrBit)

typedef long GWorldFlag;

typedef long GWorldFlags;

/* Type definition of a GWorldPtr */

typedef CGrafPtr GWorldPtr;


pascal OSErr BitmapToRegion(RgnHandle region, BitMap *bMap)
    = {0xA8D7};


pascal QDErr NewGWorld (GWorldPtr *offscreenGWorld, short pixelDepth,
        Rect *boundsRect, CTabHandle cTable, GDHandle aGDevice, GWorldFlags flags)
    = {0x7000,0xAB1D};
pascal Boolean LockPixels (PixMapHandle pm)
    = {0x7001,0xAB1D};
pascal void UnLockPixels (PixMapHandle pm)
    = {0x7002,0xAB1D};
pascal GWorldFlags UpdateGWorld (GWorldPtr *offscreenGWorld, short pixelDepth,
        Rect *boundsRect, CTabHandle cTable, GDHandle aGDevice, GWorldFlags flags)
    = {0x7003,0xAB1D};
pascal void DisposeGWorld (GWorldPtr offscreenGWorld)
    = {0x7004,0xAB1D};
pascal void GetGWorld (CGrafPtr *port, GDHandle *gdh)
    = {0x7005,0xAB1D};
pascal void SetGWorld (CGrafPtr port, GDHandle gdh)
    = {0x7006,0xAB1D};
pascal void CTabChanged (CTabHandle ctab)
    = {0x7007,0xAB1D};
pascal void PixPatChanged (PixPatHandle ppat)
    = {0x7008,0xAB1D};
pascal void PortChanged (GrafPtr port)
    = {0x7009,0xAB1D};
pascal void GDeviceChanged (GDHandle gdh)
    = {0x700A,0xAB1D};
pascal void AllowPurgePixels (PixMapHandle pm)
    = {0x700B,0xAB1D};
pascal void NoPurgePixels (PixMapHandle pm)
    = {0x700C,0xAB1D};
pascal GWorldFlags GetPixelsState (PixMapHandle pm)
    = {0x700D,0xAB1D};
pascal void SetPixelsState (PixMapHandle pm, GWorldFlags state)
    = {0x700E,0xAB1D};
pascal Ptr GetPixBaseAddr (PixMapHandle pm)
    = {0x700F,0xAB1D};
pascal QDErr NewScreenBuffer (Rect *globalRect, Boolean purgeable, GDHandle *gdh,
        PixMapHandle *offscreenPixMap)
    = {0x7010,0xAB1D};
pascal void DisposeScreenBuffer (PixMapHandle offscreenPixMap)
    = {0x7011,0xAB1D};
pascal GDHandle GetGWorldDevice (GWorldPtr offscreenGWorld)
    = {0x7012,0xAB1D};

/* New Palette Manger routines, from the <Palettes.h> MPW file. */

pascal long Entry2Index(short srcEntry)
    = {0x7000,0xAAA2};
pascal void RestoreDeviceClut(GDHandle gdh)
    = {0x7002,0xAAA2};
pascal void ResizePalette(PaletteHandle srcPalette, short dstSize)
    = {0x7003,0xAAA2};

#endif










Path: ucivax!gateway
From: [e-mail] (opcode ranger)
Subject: Where are the THINK archives?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 26 Apr 91 23:56:02 GMT
X-Vmsmail-To: @THINKC

I guess the subject says it all.  Can anyone clue me in?

RobertI

============================================================================
= [e-mail] * generic disclaimer: * "Good tea.        =
=                             * all my opinions are *  Nice house."     =
=                                * mine                *  -Worf            =
============================================================================










Path: ucivax!gateway
From: [e-mail] (Chris McNeil)
Subject: Cdev problems
Message-ID: <[e-mail]>
X-Mailer: QuickMail/SMTP interface.
Newsgroups: fa.think-c
Lines: 54
Date: 29 Apr 91 19:17:44 GMT

I have a Cdev (based on sample cdev that comes with think C) that trys to put
up a window with a message in it when itemhit = 12. This works a few times and
then my Mac freezes up. Also when this code is included if I switch the control
panel to the backgroud and then back again the Mac crashes when I close the
control panel. The code is as follows: ( I've cut out most of the code that
isn't causing me any problems.

Any suggestions, solutions etc would be most welcome.

Chris McNeil
[e-mail]

void putupdialog()



{
extern int alertact;
CharsHandle editrec;
    DialogPtr MyWindow;
    GrafPtr savePort;
    /*Boolean MyFilter();*/
    EventRecord myEvent;
    Rect windowbounds;
    int item;

    savePort=thePort;


        /* Calculate the size of the window  */

        windowbounds.top=30;
        windowbounds.left=8;
        windowbounds.right=508;
        windowbounds.bottom=(((48* 4)+windowbounds.top));

        MyWindow=NewDialog(0L,&windowbounds,"",1,2,-1L,1,1,0L);

        /* Write the message to the window    */

         SetPort(MyWindow);

    /* Restore the Graf Port */
    SetPort(savePort);

    ModalDialog(0L,item);
    DisposDialog(MyWindow);





}











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Cdev problems
Message-ID: <[e-mail]>
In-Reply-To: Chris McNeil's message of 29 Apr 91 19:17:44 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 29 Apr 91 22:14:08 GMT

Chris McNeil <[e-mail]> writes:
   I have a Cdev (based on sample cdev that comes with think C) that
   trys to put up a window with a message in it when itemhit = 12.
   This works a few times and then my Mac freezes up. Also when this
   code is included if I switch the control panel to the backgroud and
   then back again the Mac crashes when I close the control panel.

   [ ... stuff deleted ... ]

       int item;

       ModalDialog(0L,item);

This is most likely the cause of some of your problems.  You should
pass the address of item to ModalDialog, since it expects itemHit to
be a VAR parameter.

Like:  ModalDialog(0L, &item);

I have no idea why it crashes when you close the control panel.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Charles Mead)
Subject: strangeness with 'open'
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 30 Apr 91 03:31:58 GMT

I'm writing a file manager package and am using lseek, read, write, open, etc.
I have found that if I open a file without using the O_TEXT option that I
can't write text into it (which is probably the behavrior you would expect).
However, 'write' still says it's writing text in, i.e. it returns nonzero
byte values when called.  When you try to read from the file however, there's
nothing there.  I have asked a couple of UNIX C people and they seem to think
this is aberrant behavior found only on the Mac.  Any comments, criticims, etc.
Thanks.
Charles Mead ([e-mail])










Path: ucivax!gateway
From: [e-mail]
Subject: Re: strangeness with 'open'
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 58
Date: 30 Apr 91 06:01:03 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet1200349580> of Tue Apr 30 03:31:58 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 2165
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ehorvath-390>
UA-Content-ID: <MAC-1.3.4A1-618034-ehorvath-390>
MTS-Message-ID: <ehorvath1200558540>

>I'm writing a file manager package and am using lseek, read, write, open,
>etc. I have found that if I open a file without using the O_TEXT option that
>I can't write text into it (which is probably the behavrior you would
>expect). However, 'write' still says it's writing text in, i.e. it returns
>nonzero
>byte values when called.  When you try to read from the file however, there's
>nothing there.  I have asked a couple of UNIX C people and they seem to think
>this is aberrant behavior found only on the Mac.  Any comments, criticims,
>etc.
>Thanks.
>Charles Mead ([e-mail])

You don't provide a lot of detail on the nature of your failure.  However, the
following program executed flawlessly for me (link with ANSI and unix libs):
----- cut here -----
#include <unix.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <stdlib.h>

char text[] = "This is the output of the program.\r";
main ()
{
    int fildes;

    fildes = open ("thud", O_CREAT|O_WRONLY|O_TRUNC);
    if (fildes < 0) {
        fprintf (stderr, "open failed, errno = %d\n", errno);
        exit (EXIT_FAILURE);
    } else {
        write (fildes, text, strlen (text));
        close (fildes);
        exit (EXIT_SUCCESS);
    }
}
----- cut here -----

There is, however, a subtlety about end-of-line characters: notice that the
printf line (which doesn't execute, by the way) uses \n, whereas the output
text uses \r.  If I'd used O_TEXT I could use \r or \n: O_TEXT will cause the
I/O library to patch up end-of-line sequences for you on the Mac, since every
other Mac app expects \r to end TEXT-file lines.  If you write \n's to a file
not opened with O_TEXT, then try to read them in keying off \r, you may not
get the results you expect.

Also note that if "thud" doesn't exist, it gets created with both a creator
and a type of '????', where maybe you would've preferred TEXT.  If that's your
preference, use O_TEXT.  However, this program gives the content of the data
fork precisely the content of the text string.

I didn't experiment with other combinations of open() flags.  Feel free to
play with this snippet any way you see fit.

Hope that helps.

=Ned Horvath=
[e-mail]